1. Technical Field of the Invention
This invention relates to program addressability testing. More particularly, it relates to testing for memory aliasing errors in systems with large and small addresses or with addresses in different address spaces.
2. Background Art
In computer systems with large amounts of storage relative to the storage amounts formerly expected, or registers extended to be larger than formerly expected, a common bug is for code to have less-significant bits correct in a storage reference but have incorrect values for the most-significant bits.
Equivalently, registers employed for indirect addressing may be loaded with incorrect values, resulting in a final address location with incorrect most-significant bits.
Referring to FIG. 1, for example, coding or usage errors occur when code using a 31-bit address 106 is used in a 64-bit system, giving rise to missing or extra bits or wrong mode. A second addressing scheme implements a 31-bit address 106 in a 32-bit register 104 (including mode bit 103), with the extra bit (mode bit 103) used to distinguish older, first 24 bit addresses from the newer 31-bit addresses 106. In a third addressing scheme, a 64-bit address 108 is implemented in a 64-bit register 100. In a system built on this third addressing scheme, programs may switch back and forth between addressing modes. This system has 64-bit registers 100, but instructions are provided for switching between 31- and 64-bit addressing modes, using 31- and 64-bit addresses 106, 108, respectively.
In this third context, programs based on 31-bit addressing are upgraded to 64-bit programs using routines built on such instructions as set addressing mode (SAM; for example, SAM31, SAM64). Similarly, addressing mode may be set using load program status word (load PSW), branch and set mode, and branch and set save mode. These instructions, addressing modes and related structures, and other commands referenced hereafter, are described in the following IBM publications.                IBM Corporation. z/VM CP Command and Utility Reference, Version 3 Release 1.0. IBM Publication SC24-5967-00, February 2001, pages 174-178 (Define Storage Command).        IBM Corporation. Enterprise Systems Architecture/390 Principles of Operation. IBM Publication SA22-7201-08, 2003, pages iii-xv, 1-9, 2-2 to 2-5, 3-1 to 3-8, 4-6, 5-8, 7-117 to 7-118.        IBM Corporation. z/Architecture Principles of Operation. IBM Publication SA22-7832-02, 2003, pages iii-xv, 1-2, 1-5, 1-10, 1-17, 2-2 to 2-3, 3-1 to 3-7, 3-26 to 3-62, 4-6 to 4-7, 5-7 to 5-8, 7-161 to 7-162.        
Typical problems which occur as a result of switching addressing modes include having bits off that should be on, having bits on that should be off, or having the address be used in a wrong mode. This is caused, typically, when a programmer is using a mixture of 32-bit and 64-bit operations. If there is a coding error, that error may leave a persistent residue. Thus, for example, a program moving a 64-bit address 108 into a register 100 from memory (herein called storage) should use a LG instruction (load G, where G represents a 64-bit object). However, if the program uses a simple load, only the right half 104 (including mode bit 103) of the register 100 is loaded from storage, and the register's left half 102 is left with whatever data was present before the load instruction.
In another case, the program may assume the high-order 33 bits 109 of register 100 are all zeros, and if they are not, the unintended residue in the high-order 33 bits 109 may be passed in an address to a routine expecting a clean 64-bit representation 108 of the intended 31-bit address 106, resulting in an addressing error.
In another aspect of this addressing problem, when propagating a 31-bit address into a 64-bit mode, with mode bit 103 used to differentiate between 24- and 31-bit addresses, bit 103 remains on in the high order 33 bits 109 of the 64-bit register and is used as part of the 64-bit address when, in the 31-bit mode, it is not part of the address. Thus, the programmer must distinguish a 31-bit address 106 from a 32-bit value (bits 32-63, or 32 bits).
The inverse of the above typical problems also occurs. In this case, code using a 64-bit address 108 which is beyond addressability of a 31-bit address 106 (that is, whose high order 33 bits 109 are not zeros) may erroneously pass that address to code which only tolerates 31-bit addresses. The latter code will then make references in 31-bit addressing mode, ignoring the high-order 33 bits 109 and therefore referencing the wrong memory location.
Referring to FIG. 2 in connection with FIG. 1, a program in 64-bit addressing mode attempting to access a storage location 110 by way of a 31-bit address 106 may, if the mode bit 103 is on, actually access storage location 112. Similarly, a program in 64-bit addressing mode attempting to access a storage location 110 by way of a 31-bit address 106 may, if residual bits in the left half 102 are nonzero, actually access storage at a location like location 115. This could work the other way. That is, a program attempting to access storage location 112 by use of a 64-bit address 108 may, if bit 32 is off, access storage location 110.
Referring further to FIGS. 1 and 2, a bit error may occur in the left half 102. If a bit is lost, in an address 108 for location 114 in storage 120, the program may erroneously access location 116. Or, if in 31-bit mode (analogous to losing high order 33 bits 109) the program may access location 118, when location 114 is really the desired location. Similarly, if the program is operating with a 31-bit address 106 in 64-bit mode, if there is noise in high order address bits 109, the program may erroneously access location 114 in high region 122 when location 118 in low region 124 of storage 120 is desired.
In general, depending upon extra and missing bits in an address, program access to storage 120 may be erroneously directed. This is what is generally meant by an aliasing error.
The problems in the art addressed thus far relate to a single address space 120. However, if several virtual address spaces are in use, or if both real and virtual address spaces are in use, with control register settings or other means used to identify which address space is currently referenced, there is the possibility that the wrong virtual or real address space may be referenced.
There is, therefore, a need in the art for a system and method for testing program code to identify and locate addressing errors, including extra or missing bits and wrong addressing mode. There is a further need in the art to find in a program undergoing test addressing errors across multiple real and virtual address spaces. Heretofore, recognizing and locating the source of these errors so that they may be corrected in the code under test have been very difficult.